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DISPOSITIF ET PROCEDE PERFECTIONNES DE TRAITEMENT DE 
DONNEES POUR LA GENERATION D'ALARMES AU SEIN D'UN RESEAU 
DE COMMUNICATIONS 



L'invention concerne le domaine de I'echange de donnees entre 
equipements d'un reseau de communications, et plus particulierement celui 
de la gestion d'evenements survenant au sein desdits equipements. 

Les reseaux de communications comportent generalement un 
dispositif de gestion de reseau (ou NMS pour « Network Management 
System ») cense prevenir Toperateur lorsqu'un evenement survient dans un 
equipement. Plus precisement, chaque fois que survient un evenement au 
sein d'un equipement, ou dans un materiel supervise par cet equipement, ce 
dernier delivre une notification representative dudit evenement. Cette 
notification, plus connue sous ['expression anglaise « Trap » lorsque le 
protocole de gestion du reseau est le protocole SNMP (pour « Simple 
Network Management Protocol » RFC 2571-2580), est constitute de donnees 
primaires agencees selon des formats (ou protocoles) primaires. A reception 
de ces donnees primaires le gestionnaire NMS analyse leur contenu, puis s'il 
reconnait le premier format il genere une alarme definie par des donnees 
secondares agencees selon un unique format (ou protocole) secondaire 
predefini. 

Or, du fait de leur grande variete, les equipements d'un reseau 
utilisent frequemment des formats primaires d'echange differents, difficiles, 
voire impossibles, a modifier. Par consequent, les gestionnaires NMS ne 
peuvent reconnaTtre qu'une partie des notifications qu f ils regoivent. 

Pour tenter de remedier a cet inconvenient, il a ete propose d'equiper 
le gestionnaire NMS d'un module de traitement de donnees primaires 
reposant soit sur un outil de correlation de formats, soit sur des codes de 
programmes, soit encore sur des fichiers de configuration. La premiere 
solution, reposant sur un outil de correlation, met en oeuvre des traitements 
dont la lenteur est redhibitoire. La deuxieme solution, reposant sur des codes 
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de programmes, necessite des developpements tres couteux. Enfin, la 
troisieme solution n'est pas suffisamment souple pour convenir aux situations 
dans lesquelles les formats primaires sont assez differents, ce qui est 
generalement le cas. De plus, ces solutions ne permettent generalement pas 
5 de synchroniser ou resynchroniser I'etat d'alarme des equipements au niveau 
du gestionnaire NMS. Par consequent, aucune solution proposee n'est 
reellement satisfaisante. 

L'invention a done pour but de remedier a tout ou partie des 
inconvenients precites. 

10 Elle propose a cet effet un dispositif de traitement de donnees 

comportant des moyens de traitement capables de recevoir d'equipements 
d'un reseau de communications des donnees primaires (ou notification) 
definissant des evenements dans au moins un format primaire, et de delivrer 
a un dispositif de gestion du reseau (ou gestionnaire NMS) des donnees 

is secondaires definissant des alarmes representatives des evenements, dans 
un format secondaire. 

Ce dispositif se caracterise par le fait que ses moyens de traitement 
comprennent un interpreter (ou « scripting engine ») muni de regies de 
conversion, agencees sous forme de « scripts » associes aux differents 

20 formats primaires d'evenement, et agence de maniere a convertir a Taide de 
ces regies des donnees primaires, repues dans Tun des formats primaires, en 
donnees secondaires dans le format secondaire interpretable par le dispositif 
de gestion. 

Preferentieltement, Pinterpreteur est agence pour effectuer ses 
25 conversions dans un format secondaire de fichier de configuration a I'aide 
d'un langage interprets. Plus preferentieltement encore, le format secondaire 
de fichier de configuration est un format de type XML (pour « extensible 
Markup Language » - version 1.0 recommandee par le W3C), et/ou le 
langage interprets est JavaScript (tel que defini par ECMA-262 ECMAScript : 
30 A general purpose, cross-platform programming language). 

Egalement de preference, lorsque les donnees primaires sont 
respectivement associees a des identifiants d'evenements, comme par 
exemple des identifiants d'objets (ou OID pour « Object Identifier »), 
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Tinterpreteur peut etre agence de maniere a stacker certaines au moins des 
regies de configuration en correspondance d'identifiants d'evenements 
connus. Dans ce cas, Tinterpreteur peut etre egalement agence de maniere a 
stocker au moins une regie de conversion definissant un script par defaut 
5 destine aux donnees primaires qui sont associees a un identifiant 
d'evenement inconnu. 

Avantageusement, Tinterpreteur peut etre agence de maniere a 
deduire de certaines donnees primaires re?ues (ou notification) des 
parametres d'alarme lui permettant de delivrer au dispositif de gestion une 

10 alarme parametree. Dans ce cas, les alarmes peuvent etre parametrees par 
des valeurs « codees en dur » et/ou extraites des donnees primaires, et/ou 
des valeurs extraites d'un equipement. Dans cette derniere hypothese, 
Tinterpreteur doit etre agence pour extraire d'un equipement du reseau, dont 
Tetat d'alarme est inconnu (de preference de sa base d'informations de 

is gestion ou MIB (pour « Management Information Base »)), des informations 
choisies representatives de son etat d'alarme, puis simuler remission de 
donnees primaires (ou notification) representatives de ces informations d'etat, 
de maniere a generer une alarme destinee a signaler au dispositif de gestion 
Tetat d'alarme de Tequipement 

20 Par ailleurs, les donnees primaires sont preferentiellement repues 

dans des formats primaires de type SNMP (protocole de gestion de reseau 
Internet). 

Uinvention porte egalement sur un dispositif de gestion de reseau (ou 
gestionnaire NMS) comprenant un dispositif de traitement du type de celui 

25 presente ci-avant. 

L'invention porte en outre sur un precede de traitement de donnees, 
dans lequel, a reception de donnees primaires (ou notification) transmises par 
des equipements d'un reseau de communications et definissant des 
evenements dans au moins un format primaire, on delivre a un dispositif de 

30 gestion du reseau (ou gestionnaire NMS) des donnees secondaires 
definissant des alarmes representatives des evenements, dans un format 
secondaire. 

Ce procede se caracterise par le fait que son etape de generation 
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consiste a convertir a Taide de regies de conversion, agencees sous forme de 
« scripts » associes aux differents formats primaires d'evenement, des 
donnees primaires, regues dans Tun des formats primaires, en donnees 
secondaires dans le format secondaire interpretable par le dispositif de 
gestion. 

Le precede selon invention pourra comporter de nombreuses 
caracteristiques complementaires qui pourront etre prises separement et/ou 
en combinaison, et en particulier : 

- on peut proceder a la conversion dans un format secondaire de fichier de 
configuration a I'aide d'un langage interprete. II est alors preferable que le 
format secondaire du fichier de configuration soit un format de type XML, 
et/ou que le langage interprete soit JavaScript ; 

- en presence de donnees primaires associees respectivement a des 
identifiants d'evenements, on peut associer certaines au moins des regies 
de conversion a des identifiants d'evenements connus. Dans ce cas, il est 
avantageux que Tune au moins des regies de conversion soit definie par un 
script par defaut destine a des donnees primaires associees a un identifiant 
d'evenement inconnu ; 

- on peut deduire de certaines donnees primaires regues des parametres 
d'alarme, de maniere a delivrer au dispositif de gestion une alarme 
parametree, par exemple par des valeurs « codees en dur » et/ou des 
valeurs extraites des donnees primaires et/ou des valeurs extraites d'un 
equipement ; 

- on peut extraire d'un equipement du reseau, dont Petat d'alarme est 
inconnu, des informations choisies representatives de son etat d'alarme, 
puis simuler remission de donnees primaires representatives de ces 
informations d'etat, de maniere a generer une alarme destinee a signaler 
au dispositif de gestion Tetat d'alarme de I'equipement. Cette extraction 
s'effectue preferentiellement dans la base d'informations de gestion de 
Pequipement concerne ; 

- les donnees primaires sont preferentiellement regues dans des formats 
primaires de type SNMP. 

L'invention peut notamment etre mise en oeuvre dans toutes les 
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technologies reseaux devant etre gerees, et notamment dans les reseaux de 
transmission (par exemple de type WDM t SONET, SDH), de donnees (par 
exemple de type Internet-IP ou ATM) ou de voix (par exemple de type 
classique, mobile ou NGN). 

D'autres caracteristiques et avantages de ['invention apparaltront a 
Texamen de la description detaillee ci-apres, et de Tunique figure annexee qui 
illustre de fagon schematique un exemple de realisation d'un dispositif selon 
Tinvention implante dans un gestionnaire NMS d'un reseau de 
communications. Cette figure est, pour Tessentiel, de caractere certain. En 
consequence, elle pourra non seulement servir a completer Tinvention, mais 
aussi contribuer a sa definition, le cas echeant. 

Le dispositif de traitement 1 selon Tinvention est destine a alimenter 
en alarmes un gestionnaire NMS (pour « Network Management System ») 2 
d'un reseau de communications, par exemple de type Internet. Dans 
Texemple illustre sur Tunique figure, ce dispositif 1 est implante dans le 
gestionnaire NMS 2, mais il pourrait etre implante dans un boTtier externe, 
couple audit gestionnaire NMS. 

Le reseau de communications comporte une multiplicity 
d'equipements de reseau 3, comme par exemple des serveurs, des 
terminaux, des commutateurs ou des routeurs, pouvant echanger des 
donnees selon un protocole de gestion de reseau avec le gestionnaire NMS 
2. 

Dans ce qui suit, on considere a titre d'exemple non limitatif que le 
reseau de communications est de type Internet (IP) et que le protocole de 
gestion du reseau est le protocole SNMP (pour « Simple Network 
Management Protocol » RFC 2571-2580). Bien entendu, Tinvention s'applique 
a d'autres types de reseau, comme par exemple aux reseaux de transmission 
de type WDM, SONET ou SDH, de donnees de type ATM, ou de voix de type 
classique, mobile ou NGN, et a d'autres protocoles de gestion de reseau, 
comme par exemple TL1 ou CORBA. Les equipements 3 du reseau sont 
agences pour delivrer au gestionnaire NMS 2 des notifications (ou 
messages), ici de type « Trap », definies par des donnees primaires 
agencees selon un format (ou protocole) primaire, ici de type SNMP, chaque 
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fois que survient un evenement en leur sein, ou dans un equipement 'ou 
materiel qu'ils controlent Les donnees primaires d'une notification definissent 
par consequent un evenement survenu dans un equipement 3. Une 
multiplicity de formats primaires differents peut coexister au sein du reseau. 
5 Par ailleurs, chaque notification est preferentiellement associee a un 
identifiant representatif d'un type d'evenement. 

Le dispositif de traitement 1 comprend un module de traitement 4 
comportant un interpreter (ou « scripting engine ») 5 disposant d'une 
multiplicite de regies de conversion agencees sous la forme de « scripts » 

10 associes a une multiplicite de formats primaires d'evenement differents. 

Plus precisement, a chaque format primaire correspond un script 
particulier (ou regle(s) de conversion), preferentiellement stocke dans une 
memoire 6 en correspondance de Tun des identifiants d'evenements contenus 
dans les notifications (ou Traps). II est egalement preferable de prevoir au 

is moins un script par defaut pour traiter (ou initier le traitement) les donnees 
primaires agencees selon un format primaire qui est associe a un identifiant 
d'evenement inconnu. 

Ainsi, iorsqu'un interpreter 5 report une notification (ou Trap), il en 
extrait Tidentifiant d'evenement et determine la regie de configuration (ou 

20 script) stockee qui lui correspond. II peut alors appliquer ce script (ou regie) 
aux donnees primaires definissant la notification, de maniere a generer une 
alarme definie par des donnees secondaires agencees dans un langage 
interprets et selon un unique format secondaire interpretable par un module 
de controle 7 du gestionnaire NMS 2. En d'autres termes, les donnees 

25 primaires re?ues, agencees selon un format primaire et representatives d'un 
evenement, sont « converges » en donnees secondaires agencees selon un 
format secondaire et dans un langage interprets. 

A reception d'une telle alarme, le module de controle 7 du 
gestionnaire NMS 2 peut alors provoquer I'afftchage de i'alarme sur un ecran 

30 de controle dudit gestionnaire NMS et/ou decider d'action(s) a entreprendre 
dans le reseau pour tenir compte de I'alarme et/ou remedier a sa cause. 

L'interpreteur 5 est agence, a reception de donnees primaires, pour 
generer, a Taide du script qui correspond aux donnees primaires regues, une 
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alarme definie par des donnees secondaires. Dans un mode de realisation 
preferentiel, ces donnees secondaires sont agencees sous la forme d'un 
fichier de configuration d'alarme selon un format (ou protocole) secondaire, de 
preference de type XML (pour « extensible Markup Language »), et dans un 
5 langage interprets (ou « scripting language »), de preference de type 
JavaScript (tel que defini par ECMA-262 ECMAScript : A general purpose, 
cross-platform programming language). Plus preferentiellement encore, on 
choisit la version 1.0, du format XML recommandee par W3C. 

Bien entendu, d'autres langages interpretes (ou « scripting 

10 languages ») et d'autres formats secondaires pourraient etre envisages. Ainsi, 
XML peut etre remplace par des formats textes proprietaires. De meme, le 
langage JavaScript des scripts peut etre remplace, par exemple, par 
VisualBasic, TCL, Perl ou encore Python. 

Dans cet exemple, Pidentifiant d'evenement, permettant a 

is Tinterpreteur 5 de determiner le script correspondant au format primaire des 
donnees primaires regues, est preferentiellement de type OID (« Object 
Identifier » - identifiant de type simple ASN.1 permettant d'identifier un objet 
tel qu'un ev6nement), dans la mesure ou le langage interprets, utilise par 
Tinterpreteur 5 pour generer les fichiers de configuration (donnees 

20 secondaires), est JavaScript 

La syntaxe utilisee pour generer les fichiers de configuration d'alarme 
(ou donnees secondaires) est done ici une combinaison de XML et de 
JavaScript. Plus precisement, d'une premiere part, la structure generate du 
fichier est de type XML, d'une deuxieme part, les donnees secondaires, 

25 definissant Talarme associee a une notification OID regue, sont toujours 
encadrees par deux blocs (ou « tags ») XML, d'une troisieme part, chaque 
champ de Talarme possede une unique entree, et d'une quatrieme part, 
chaque entree de Talarme est soit une constante, soit une expression 
JavaScript. 

30 Ainsi, lorsque toutes les entrees de Palarme sont des constantes, le 

fichier de configuration d'alarme est principalement de type XML. Par 
exemple, il se presente sous la forme <SEVERITY>Critical</SEVERITY>. 
Lorsque certaines au moins des entrees de Talarme sont des expressions 
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JavaScript, un maximum de souplesse peut etre obtenu. Le fichier se 
presente alors, par exemple, sous la forme <SEVERITY> 
(trapget(« 1 .2.3.4 »)==2) ? Critical : Major</SEVERITY>. 

Certains champs de i'alarme generee peuvent etre optionnels ou 
5 presenter une valeur par defaut. 

Grace aux scripts, il est possible de tirer pleinement partie des 
informations contenues dans les donnees primaires qui constituent les 
notifications re?ues. De nombreux traitements, notamment logiques et/ou 
calculatoires, peuvent etre ainsi appliques aux parametres qui definissent les 
10 evenements signales par les equipements 3 du reseau. Par consequent, 
Pinterpreteur 5 peut non seulement generer une alarme representative d'un 
evenement, mais egalement accompagner cette alarme de parametres (ou de 
valeurs de parametres) susceptibles d'en faciliter le traitement au niveau du 
gestionnaire NMS 2. 

is Les alarmes peuvent ainsi §tre parametrees par des valeurs « codees 

en dur» et/ou extraites de la notification (ou Trap) et/ou extraites d'un 
equipernent dont on a regu une notification (ou Trap). 

Afin de mettre en ceuvre cette troisieme possibility, I'interpreteur 5 doit 
etre agence de maniere a adresser a un equipernent, dont il a eventuellement 

20 regu des donnees primaires representatives d'un etat d'alarme inconnu, un 
message requerant de sa part certaines informations susceptibles de 
permettre la determination dudit etat d'alarme. Generalement, ces 
informations sont contenues dans la base d'informations de gestion 8 (ou MIB 
pour « Management Information Base ») de Tequipement 3. 

25 Grace a cet agencement lui permettant d'extraire des informations 

d'un equipernent 3 distant, et notamment de sa MIB 8, le dispositif selon 
('invention 1 peut assurer une fonction de synchronisation et 
resynchronisation de Tetat d'alarme de chaque equipernent. En effet, chaque 
fois que le gestionnaire NMS du reseau 2 (ou son dispositif de traitement 1) 

30 est redemarre ou deconnecte du reste du reseau, par exemple en cas de 
panne ou d'intervention de maintenance, il doit etre, d'une part, resynchronise 
par rapport aux etats d'alarmes respectifs des equipements 3 du reseau qui 
etaient presents au moment de sa deconnexion, lesquels etats ont pu 
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evoluer, et d'autre part, synchronise par rapport aux etats d'alarmes respectifs 
des nouveaux equipements 3 du reseau, lesquels etats lui sont inconnus. II en 
va de meme chaque fois qu'un nouvel equipement 3 se connecte au reseau 
ou qu'un ancien equipement se reconnecte au reseau. 
5 Cette fonction peut etre assuree par une ou plusieurs regies, par 

exemple stockees dans la memoire 6, soit automatiquement lors de chaque 
mise en fonctionnement et/ou chaque fois que I'interpreteur 5 est averti d'une 
(re)connexion par le module de controle 7 du gestionnaire NMS 2 du reseau, 
soit semi-automatiquement chaque fois que la personne responsable de la 

10 gestion du reseau en donne I'ordre a I'interpreteur 5. 

La ou les regies de (re)synchronisation sont agencees pour examiner 
le contenu de la MIB du ou des equipements 3 designes, de maniere a 
extraire les informations (parametre(s) ou valeur(s) de parametre(s)) 
definissant leur(s) etat(s) d'alarme. Mais, ces regies peuvent egalement servir 

is a verifier ou controler la valeur d'un ou plusieurs parametres. Comme indique 
ci-dessus, dans certaines situations tous les equipements du reseau, qui 
dialoguent avec le gestionnaire NMS 2, peuvent faire Tobjet d'un examen a 
Taide des regies de (re)synchronisation. 

La ou les regies de (re)synchronisation peuvent etre agencees de 

20 maniere a simuler remission d'une notification (ou Trap) a I'interieur du 
gestionnaire NMS 2. Plus precisement, elles indiquent les notifications (ou 
Traps) que Tequipement 3 aurait du envoyer pour passer d'un etat sans 
alarme a son etat en cours. Ces notifications (ou Traps) simulees font ensuite 
Tobjet d'une conversion semblable a celle appliquee aux notifications reelles. 

25 Le module de traitement 4 du dispositif 1, et son interpreter 5, 

peuvent etre respectivement realises sous la forme de circuits electroniques, 
de modules logiciels (ou informatiques), ou d'une combinaison de circuits et 
de logiciels. 

L'invention offre egalement un procede de traitement de donnees, 
30 dans lequel, a reception de donnees primaires transmises par des 
equipements 3 d'un reseau de communications et definissant des 
evenements dans au moins un format primaire, on delivre a un dispositif de 
gestion du reseau 2 (ou gestionnaire NMS) des donnees secondaires qui 
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definissent des alarmes representatives de ces evenements, dans lin format 
secondaire. 

Celui-ci peut etre mis en oeuvre a I'aide du dispositif de traitement 
presente ct-avant La fonction principale et les sous-fonctions optionnelles 
assurees par les etapes de ce procede etant sensiblement identiques a celles 
assurees par les differents moyens constituant le dispositif de traitement 1 , 
seule sera resumee ci-apres I'etape mettant en oeuvre la fonction principale 
du procede selon I'invention. 

Ce procede se caracterise par le fait que son etape de generation 
consiste a convertir a I'aide de regies de conversion, agencees sous forme de 
« scripts » associes aux differents formats primaires d'evenement, des 
donnees primaires, regues dans Tun des formats primaires, en donnees 
secondaires dans le format secondaire interpretable par le dispositif de 
gestion 2. 

Grace a invention, il n'est plus necessaire de recourir a la 
programmation, ce qui permet de reduire les couts de developpement. De 
plus, les scripts procurent une grande souplesse d'utilisation et une grande 
rapidite de traitement (plusieurs dizaines de notifications (ou Traps) par 
seconde), et permettent une adaptation rapide a tous les types de formats 
primaires. En outre, I'invention permet une (re)synchronisation. 

^invention ne se limite pas aux modes de realisation de procede et 
dispositifs decrits ci-avant, seulement a titre d'exemple, mais elle englobe 
toutes les variantes que pourra envisager Thomme de Tart dans le cadre des 
revendications ci-aprds. 
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REVENDICATIONS 

1. Disposiiif de traitement de donnees (1) comportant des moyens de 
traitement (4) propres a recevoir d'equipements (3) d'un reseau de 
communications des donnees primaires definissant des evenements dans au 
moins un format primaire, et a delivrer a un dispositif de gestion dudit reseau 
(2) des donnees secondaires definissant des alarmes representatives desdits 
evenements, dans un format secondaire, caracterise en ce que lesdits 
moyens de traitement (4) comprennent un interpreter (5) muni de regies de 
conversion, agencees sous forme de « scripts » associes aux differents 
formats primaires d'evenement, et agence pour convertir a I'aide desdites 
regies des donnees primaires, regues dans Tun desdits formats primaires, en 
donnees secondaires dans ledit format secondaire interpretable par ledit 
dispositif de gestion (2). 

2. Dispositif selon la revendication 1 , caracterise en ce que ledit 
interpreter (5) est agence pour effectuer lesdites conversions dans un format 
secondaire de fichier de configuration a I'aide d'un langage interpreter - 

3. Dispositif selon la revendication 2, caracterise en ce que ledit format 
secondaire de fichier de configuration est un format choisi dans uni groupe 
comprenant XML et les formats textes proprietaires. 

4. Dispositif selon Tune des revendications 2 et 3, caracterise en ce 
que ledit langage interprets est choisi dans un groupe comprenant au moins 
JavaScript, VisualBasic, TCL, Perl et Python. 

5. Dispositif selon Tune des revendications 1 a 4, caracterise en ce 
que, en presence de donnees primaires associees respectivement a des 
identifiants d'evenements, ledit interpreter (5) est agence pour stocker 
certaines au moins desdites regies en correspondance d'identifiants 
d'evenements connus. 

6. Dispositif selon la revendication 5, caracterise en ce que ledit 
interpreter (5) est agence pour stocker au moins une regie de conversion 
definissant un script par defaut destine aux donnees primaires associees a un 
identifiant d'evenement inconnu. 



1er depot 

12 



7. Dispositif selon Tune des revendications 1 a 6, caracterise en ce que 
ledit interpreter (5) est agence pour deduire de certaines donnees primaires 
re?ues des parametres d'alarme, de maniere a delivrer audit dispositif de 
gestion (2) une alarme parametree. 
5 8. Dispositif selon la revendication 7, caracterise en ce que ledit 

interpreter (5) est agence pour delivrer au dit dispositif de gestion (2) des 
alarmes parametrees par des valeurs « codees en dur ». 

9. Dispositif selon Tune des revendications 7 et 8, caracterise en ce 
que ledit interpreter (5) est agence pour delivrer audit dispositif de gestion (2) 

10 des alarmes parametrees par des valeurs extraites desdites donnees 
primaires. 

10. Dispositif selon Tune des revendications 1 a 9, caracterise en ce 
que, lorsque I'etat d'alarme d'un equipement (3) du reseau est inconnu, ledit 
interpreter (5) est agence pour extraire dudit equipement (3) des 

15 informations choisies representatives dudit etat d'alarme, puis simuler 
remission de donnees primaires representatives desdites informations d'etat, 
de maniere a generer une alarme destinee a signaler au dispositif de gestion 
(2) I'etat d'alarme dudit equipement (3). 

11. Dispositif selon la revendication 10 en combinaison avec Tune des 
20 revendications 7 a 9, caracterise en ce que ledit interpreter (5) est agence 

pour delivrer audit dispositif de gestion (2) des alarmes parametrees par des 
valeurs extraites de ('equipement duquel il a regu des donnees primaires. 

12. Dispositif selon Tune des revendications 10 et 11, caracterise en ce 
que ledit interpreter (5) est agence pour extraire lesdites informations ou 

25 valeurs d'une base d'informations de gestion (8) de I'equipement concerne. 

13. Dispositif selon Tune des revendications 1 a 12, caracterise en ce 
que lesdites donnees primaires sont revues dans des formats primaires de 
type SNMP. 

14. Dispositif de gestion de reseau (2), caracterise en ce qu'il comprend 
30 un dispositif de traitement (1) selon Tune des revendications precedentes. 

15. Procede de traitement de donnees, dans lequel, a reception de 
donnees primaires transmises par des equipements (3) d'un reseau de 
communications et definissant des evenements dans au moins un format 
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primaire, on delivre a un dispositif de gestion du reseau (2) des donnees 
secondaires definissant des alarrnes representatives desdits evenements, 
dans un format secondaire, caracterise en ce que ladite generation consiste a 
convertir a Paide de regies de conversion, agencees sous forme de « scripts » 
associes aux differents formats primaires d'evenement, des donnees 
primaires, re?ues dans Tun desdits formats primaires, en donnees 
secondaires dans iedit format secondaire interpretable par ledit dispositif de 
gestion (2). 

16. Procede selon la revendication 15, caracterise en ce que Ton 
procede a la conversion dans un format secondaire de fichier de configuration 
a Paide d'un langage interprete. 

17. Dispositif seion la revendication 16, caracterise en ce que ledit 
format secondaire de fichier de configuration est un format choisi dans un 
groupe comprenant XML et les formats textes proprietaires. 

18. Dispositif selon Tune des revendications 16 et 17, caracterise en ce 
que ledit langage interprete est choisi dans un groupe comprenant au moins 
JavaScript, VisualBasic, TCL, Peri et Python. 

19. Procede selon Tune des revendications 15 a 18, caracterise en ce 
que, en presence de donnees primaires associees respectivement a des 
identifiants d'evenements, on associe certaines au moins desdites regies de 
conversion a des identifiants d'evenements connus. 

20. Procede selon la revendication 19, caracterise en ce que Tune au 
moins desdites regies de conversion definit un script par defaut destine a des 
donnees primaires associees a un identifiant d'evenement inconnu. 

21. Procede selon Tune des revendications 15 a 20, caracterise en ce 
que Ton deduit de certaines donnees primaires regues des parametres 
d'alarme, de maniere a delivrer audit dispositif de gestion (2) une alarme 
parametree. 

22. Procede selon la revendication 21, caracterise en ce que Pon delivre 
audit dispositif de gestion (2) des alarmes parametrees par des valeurs 
« codees en dur ». 

23. Procede selon Tune des revendications 21 et 22, caracterise en ce 
que Pon delivre audit dispositif de gestion (2) des alarmes parametrees par 
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des valeurs extraites desdites donnees primaires. 

24. Procede seion Tune des revendications 15 a 23, caracterise en ce 
que, lorsque I'etat d'alarme d'un equipement (3) du reseau est inconnu, on 
extrait dudit equipement (3) des informations choisies representatives dudit 

5 etat d'alarme, puis on simule remission de donnees primaires representatives 
desdites informations d'etat, de maniere a generer une alarme destinee a 
signaler au dispositif de gestion (2) I'etat d'alarme dudit equipement (3). 

25. Procede selon fa revendication 24 en combinaison avec Tune des 
revendications 21 a 23, caracterise en ce que Ton delivre audit dispositif de 

10 gestion (2) des alarmes parametrees par des valeurs extraites de 
I'equipement (3) duquel il a regu des donnees primaires. 

26. Procede selon Tune des revendications 24 et 25, caracterise en ce 
que Ton extrait lesdites informations ou valeurs d'une base d'informations de 
gestion (8) de I'equipement (3) concerne. 

is 27. Procede selon Tune des revendications 15 a 26, caracterise en ce 

que lesdites donnees primaires sont regues dans des formats primaires de 
type SNMP. 

28. Utilisation des procede, dispositif de traitement (1) et dispositif de 
gestion (2) selon Tune des revendications precedentes dans les technologies 

20 reseaux devant etre gerees. 

29. Utilisation selon la revendication 28, caracterise en ce que lesdites 
technologies reseaux sont choisies dans un groupe comprenant les reseaux 
de transmission, en particulier de type WDM, SONET et SDH, de donnees, 
en particulier de type Internet-IP et ATM, et de voix, en particulier de type 

25 classique, mobile et NGN. 
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